Не так давно мы писали про документ "VMware Virtual SAN Ready Nodes", в котором приведены примеры серверных конфигураций от различных производителей, подходящих в качестве готовых узлов отказоустойчивого кластера хранилищ VMware Virtual SAN.
На прошлой неделе компания VMware провела обещанное обновление этого документа, добавив туда новые серверные системы от Cisco (4 спецификации) и Hitachi (1 спецификация). Таким образом, теперь в документе есть 29 вариантов конфигураций для следующих вендоров серверного оборудования:
Dell (3 узла)
Fujitsu (5 узлов)
HP (10 узлов)
SuperMicro (6 узлов)
Cisco (4 узла)
Hitachi (1 узел)
Напомним, что к каждой спецификации на сервер прилагается профиль нагрузки, для которой предлагается его использовать, например, VDI-инфраструктура с числом виртуальных ПК до 100 или серверная инфраструктура на 60 ВМ. Также прилагается примерная конфигурация виртуальной машины, например: Virtual Machine Profle: 2 vCPU, 6 GB Memory, 2 x 60 GB virtual disks.
Кроме того, были сделаны следующие добавления:
Для серверов Dell указаны партномера (DellStar Solution IDs - только штаты), работа над партномерами для других вендоров - в процессе. Для большинства узлов будет единый SKU для всех вендоров.
Сбалансировано количество дисков для конфигураций с несколькими дисковыми группами.
Для всех узлов (кроме Hitachi) была добавлена USB/SD card, с которой можно грузить ESXi.
Пока нет SKU для данных узлов, вы можете просто присылать документ "VMware Virtual SAN Ready Nodes" вендору и говорить что-то в стиле "хочу такую штучку".
Может быть кто-то из вас в курсе: был такой стартап StorSimple, производивший облачные системы хранения данных, купленный в 2012 году компанией Microsoft. Подход StorSimple подразумевает хранение часто используемых данных на стороне частного облака компании и передачу остальных данных в публичное облако Microsoft Azure. То есть это решение, помимо, собственно, хранения данных, выступает еще и как Cloud Storage Gateway (напомним также, у Amazon есть подобное решение).
Тома на этих массивах (сделаны они на базе хранилищ Xyratex - сейчас это Seagate) доступны по интерфейсу iSCSI (ожидается поддержка SMB), в качестве накопителей используются диски SSD и SAS. Данные уровня Tier 1 хранятся на этих дисках, а редко используемые данные перемещаются в облако Azure, при этом создается как бы "растянутый" том между локальным и облачным хранилищем. При этом, конечно же, данные продолжают оставаться доступными пользователям - они только испытывают несколько бОльшие задержки при доступе к ним. Основное назначение массивов StorSimple - неструктурированные данные, то есть "файловые помойки" из документов Office и т.п. При этом пользователи получают такие бонусы облачной инфраструктуры, как Disaster Recovery и прочее.
На прошлой неделе компания Microsoft сделала сразу несколько интересных анонсов, касающихся решений StorSimple:
Новый облачный сервис "Microsoft Azure StorSimple".
Массивы StorSimple 8100 и 8600
Сырая емкость массива StorSimple 8100 составляет 15 ТБ, а массива 8600 - 40 ТБ. За счет использования технологий компрессии и дедупликации данных можно достичь 75 ТБ эффективной емкости для модели 8100 и 200 ТБ для модели 8600. Если же используются облачные хранилища Azure, то совокупный объем хранения на устройство может достигать 200 ТБ и 500 ТБ соответственно.
Эти массивы будут доступны к заказу с 1 августа 2014 года. Полные спецификации на них доступны по этой ссылке, а краткая информация по их возможностям доступна тут.
StorSimple Virtual Appliance
Виртуальный модуль StorSimple Virtual Appliance размещается на стороне публичного облака Windows Azure и позволяет проводить репликацию данных в виртуальные машины с массивов StorSimple серии 8000 (более ранние не поддерживаются) в облако. Далее можно уже получать доступ к этим данным, не затрагивая производственное окружение (например, анализ данных).
Также важным моментом тут являются возможности восстановления в случае сбоя - если вы потеряете аппаратный модуль StorSimple, то всегда сможете восстановить данные, отреплицированные в облако.
При этом восстановление в случае сбоя хранилища StorSimple или потери данных выглядит очень элегантно - вы просто монтируете тома с сервиса Azure к новому или уже существующему дисковому массиву StorSimple.
Сервис Microsoft Azure StorSimple
Одновременно с запуском новых массивов и виртуальных модулей компания Microsoft анонсировала и новый сервис Azure StorSimple, который и обеспечивает управление гибридной инфраструктурой хранения.
Центральная консоль Azure StorSimple Manager позволяет из единой точки управлять дисковыми массивами серии 8000, а также виртуальными модулями StorSimple Virtual Appliance:
Из нее же и происходит бэкап и восстановление данных из облака, здесь же отслеживается производительность и заполненность доступных емкостей хранилищ.
Более подробнее о семействе решений StorSimple можно узнать на этой странице (а также в блоге Microsoft). Кстати, если кому-то интересна стоимость решений, то вот штатовский прайс:
За модель 8600 придется отвалить аж 170 килобаксов. Не знаю, нужно ли кому-то такое решение у нас тут, не привыкших к таким дорогим штукам.
Как мы писали недавно, в новой версии платформы VMware vSphere 6, которая сейчас находится в стадии публичной беты, появились возможности использования томов VVols (о которых мы писали здесь). Сейчас эта функциональность также находится в бете и доступна для загрузки вот тут.
Концепция VVol (она же VM Volumes) увеличивает уровень гранулярности работы хост-сервера с хранилищем за счет непосредственных операций с виртуальной машиной, минуя сущности "LUN->том VMFS->Datastore". Тома VVol является неким аналогом существующих сегодня LUN, но с меньшим уровнем гранулярности операций по сравнению с томами VMFS (последние, как правило, создаются из одного LUN). Таким образом, ВМ находится на одном VVol как всадник на лошади.
Чтобы виртуальные машины можно было создавать на томах VVols и производить с ними различные операции, нужно чтобы дисковый массив поддерживал такой интерфейс как vSphere APIs for Storage Awareness (VASA). Через этот API возможна передача функций, обычно выполняемых хостом ESXi, на сторону аппаратного хранилища. Кроме того, есть также интерфейс vSphere Storage API – Array Integration (VAAI), который также используется для offloading'а операций на сторону массива, особенно когда дело касается операций миграции и клонирования ВМ.
Давайте посмотрим, как эти два API (VASA и VAAI) работают с хранилищем при операциях клонирования виртуальных машин, которые часто нужны в инфраструктуре виртуальных ПК на базе VMware Horizon View.
Сценарий 1 - клонирование ВМ в рамках одного контейнера VVol
В этом случае через API VASA вызывается функция cloneVirtualVolume, которая полностью передает на сторону дискового массива операцию клонирования ВМ:
Сценарий 2 - клонирование ВМ в рамках разных VVol
В этом случае все зависит от того, на каких хранилищах находятся данные VVol. Если VVol-a и VVol-b находятся на двух массивах одного вендора, настроенных единообразно, и управляются одним VASA Provider, то в этом случае используется API VASA и вызывается функция cloneVirtualVolume.
Если же VVol-a и VVol-b находятся на одном массиве и настроены по-разному, либо хранилища VVol-a и VVol-b находятся на двух массивах разных вендоров или моделей, то операция через VASA API может не пройти. Тогда происходит переключение на VAAI API, который использует датамувер ESXi (vmkernel data mover) и примитивы VAAI для клонирования виртуальной машины. При этом в случае неудачи передачи операций клонирования на сторону массива датамувер может начать перемещать данные через хост ESXi (подробнее - тут):
Конечно же, предпочтительнее делать все через VASA API - такая операция пройдет быстрее, поскольку в ней не будет задействован хост ESXi. Поэтому тут важна унификация конфигурации хранилищ и дисковых массивов в инфраструктуре. Ну и надо, конечно же, смотреть, чтобы закупаемые массивы в полной мере поддерживали VASA и VAAI.
Сценарий 3 - клонирование ВМ с тома VMFS на VVol
Если получается так, что ВМ надо склонировать с тома VMFS на хранилище VVol, то тут будет работать только операция XCOPY / WRITE_SAME интерфейса VAAI.
При этом работает это только для операции в направлении VMFS->VVol, при обратном клонировании этот API использован не будет.
Узнать больше о томах VVol и позадавать вопросы на эту тему вы можете на специальной странице Virtual Volumes beta community.
Это гостевой пост нашего спонсора - компании ИТ-ГРАД, имеющей высокую компетенцию в продуктах Cisco.
Cisco UCS Director — это программный продукт, который автоматизирует управление разнородной ИТ инфраструктурой центра обработки данных. В этом посте я коротко опишу, для чего этот продукт предназначен и какие задачи решает.
Возможно, не все знают расшифровку аббревиатуры UCS. UCS (Unified Computing System) — это серверная платформа компании Cisco, которая базируется на линейках Rack и Blade. Естественно, что CISCO позиционирует UCS Director как решение, которое хоть и универсально, но наиболее полно раскрывает свои функциональные возможности в комплексе с оборудованием линейки UCS. Поэтому сначала скажем пару слов про сервера CISCO UCS.
Cервера Cisco UCS
Особенность серверной платформы Cisco UCS в том, что в конфигурации есть одна блейд-корзина и некоторый набор серверов. При этом нет градации решений и есть внутренний коммутатор — модель 62 серии, Fabric Interconnect.
Продуктовая линейка Cisco отображена на рисунке ниже.
Недавно компания VMware выпустила интересный документ "VMware Virtual SAN Ready Nodes", в котором приведены примеры серверных конфигураций от различных производителей, которые подходят в качестве узлов отказоустойчивого кластера хранилищ VMware Virtual SAN.
В обновленной версии документа были удалены некоторые старые конфигурации серверов, а новые добавлены. В ближайшие несколько недель ожидается пополнение документа новыми моделями и конфигурациями узлов.
К каждой спецификации на сервер прилагается профиль нагрузки, для которой предлагается его использовать, например, VDI-инфраструктура с числом виртуальных ПК до 100 или серверная инфраструктура на 60 ВМ. Также прилагается примерная конфигурация виртуальной машины, например:
Пока в документе есть серверы только четырех производителей (но скоро точно будет больше):
Dell
Fujitsu
HP
SuperMicro
Также у компании VMware на тему выбора и сайзинга кластеров Virtua SAN есть полезный документ "Virtual SAN Hardware Quick Reference Guide", где рассматриваются различные профили нагрузок виртуальных машин, размещенных на хранилищах отказоустойчивого кластера VSAN.
В первой таблице документа в столбцах приведены примеры нагрузок (например, полные клоны виртуальных десктопов или средняя серверная нагрузка), а в строчках рассматриваются различные аппаратные характеристики узлов, такие как вычислительные мощности, число дисков и их емкость, память, сетевые адаптеры и т.п.:
Также в документе есть рекомендации по сайзингу кластера хранилищ, а также рекомендуемым аппаратным характеристикам (например, число дисковых групп или необходимая минимальная глубина очереди на дисковом контроллере).
Публикуем очередной гостевой пост компании ИТ-ГРАД. Никто не скажет лучше про продукт, чем пиарщики его вендора. Поэтому мы просто процитируем одну из брошюр NetApp о новоиспеченной E2700 серии: СХД NetApp E2700 представляет собой простое решение для хранения данных в средах SAN. Она легко интегрируется практически в любые среды хранения данных, основанные на приложениях, предлагает множество вариантов хостингового подключения и поддерживает различные типы дисков и дисковых полок...
Мы достаточно часто пишем о средстве для создания отказоустойчивых кластеров VMware Virtual SAN (статьи можно найти по тэгу VSAN). Не так давно мы писали про документ, который позволяет правильно выбрать серверное оборудование для создания кластеров VSAN, а в этой заметке на основе информации от Дункана Эппинга, мы расскажем о выборе дисков для Virtual SAN.
Как известно, на одном хосте VMware ESXi, являющимся узлом VSAN, может быть до пяти дисковых групп (Disk Groups), каждая из которых содержит один SSD-диск и от 1 до 7 HDD-дисков:
Возникает резонный вопрос, что лучше - иметь одну дисковую группу большой емкости или несколько дисковых групп емкостью поменьше. Например, у вас такие требования к кластеру VSAN:
Всего нужно емкости : 20 ТБ
Всего емкости флэш-накопителей (10% по best practices): 2 ТБ
Всего хостов ESXi: 5
В этом случае на каждом хосте можно использовать одну из двух альтернативных конфигураций:
2 x 2 ТБ SAS-диска и 1 x 400 ГБ флэш-диск (одна дисковая группа)
4 x 1 ТБ SAS-диска и 2 x 200 ГБ флэш-диска (две дисковых группы)
Тут получается три аспекта, на которые влияет выбор конфигурации:
SSD-диск+HDD-диски дисковой группы являются единой точкой отказа (fault domain), так как отказ единственного SSD-накопителя приведет к отказу дисковой группы в целом. В случае отказа флэш-накопителя данные вы, конечно, не потеряете, но понадобится некоторое время, чтобы восстановить избыточную конфигурацию. Так что чем больше групп, тем лучше.
С точки зрения производительности - также лучше иметь две дисковых группы. Как вы знаете SSD-диск используется для кэширования данных, а один диск большей емкости, хоть и выжимает больше IOPS, но не намного. То есть, в первом случае, например, вы будете получать на кэше 36 000 IOPS, а во втором 2 x 32 000 IOPS. Аналогично, больше иопсов будут выжимать и HDD-диски. Очевидно, второй случай с точки зрения производительности - выгоднее.
Затраты - здесь надо балансировать между оптимальной емкостью SSD-накопителей и HDD-дисков. Диски большой емкости, начиная с какой-то точки, стоят намного дороже. Тут второй вариант тоже в плюсе.
Итого - несколько дисковых групп на хосте небольшой емкости лучше одной гигантской дисковой группы.
Таги: VMware, VSAN, Virtual SAN, Hardware, Performance, HA, Blogs
Компания VMware выпустила полезный документ VMware Virtual SAN Hardware Design Guide, который позволяет получить информацию о том, как правильно выбрать аппаратное обеспечение для построения отказоустойчивого кластера хранилищ на базе локальных дисков серверов - VMware Virtual SAN.
Пример правильного узла для кластера VSAN:
Внутри документа вы найдете информацию о том, как выбрать:
Форм-фактор серверов
Загрузочные устройства
Флэш-накопители
HDD-диски
Контроллеры хранилищ
Сетевые адаптеры
Ну и, конечно же, не стоит забывать про ресурс VMware Hardware Compatibility Guide (HCL), где можно найти актуальный список аппаратного обеспечения, совместимого с различными продуктами и технологиями VMware.
Для тех, кто задумался о промышленном внедрении VMware VSAN, документ - мастрид.
Мы много писали про функции ускорения 3D-графики в решении для виртуализации настольных ПК VMware View (например, тут и тут). Это режимы vSGA и vDGA, поддержка которых появилась еще в версии VMware View 5.2, но полноценно была добавлена только в версии VMware View 5.3. Ниже мы расскажем о некоторых аспектах использования этих режимов, опираясь на полезнейший документ "Graphics Acceleration in VMware
Horizon View Virtual Desktops", где помимо теории даны и практические советы по настройке инфраструктуры для работы виртуальных машин в режимах vSGA и vDGA.
Итак, начнем с определений:
Soft 3D - рендеринг 3D-картинки без использования адаптера на основе программных техник с использованием памяти сервера.
vDGA - выделение отдельного графического адаптера (GPU) одной виртуальной машине.
vSGA - использование общего графического адаптера несколькими виртуальными машинами.
Сразу отметим, что забота о поддержке режимов vDGA и vSGA лежит на плечах вендоров графических адаптеров. Пока этим в достаточной степени прославилась только компания NVIDIA.
Ниже рассмотрим картинку, на которой представлены варианты использования графических режимов для различных типов задач, которые предполагаются для работников, использующих виртуальные ПК:
Условно тут можно выделить 4 типа пользователей, касательно графически интенсивных нагрузок:
Task Worker - обычный сотрудник (например, программист или менеджер по продажам), который не использует специальных графических программ и тяжелых нагрузок. Для него вполне подойдет софтверный рендер
Knowledge Worker - этот человек имеет в своем распоряжении некоторое программное обеспечение, трубующее работы с графической подсистемой (например, иногда запускает Adobe Photoshop или смотрит видеоролики). Некоторым (в зависимости от частоты использования этих средств) вполне подойдет софтверный рендер, но кому-то будет нужная машина с поддержкой аппаратного рендеринга (но, скорее всего, в режиме vSGA).
Desktop Power User - этот человек уже интенсивно работает с графическими пакетами, возможно, на нескольких мониторах. При этом используются графические библиотеки OpenGL или DirectX (но не самых последних версий).
Workstation User - этот пользователь профессионально использует виртуальный десктоп для графически-интенсивных нагрузок (например, CAD-приложения или приложения для обработки и кодирования видео). Отличительная черта таких пользователей - профессиональное использование основного инструмента, требовательного к графике.
Соответственно, на диаграмме видно, когда и какой режим работы с графикой нужно использовать, в зависимости от категории пользователей. Практически это выглядит следующим образом: например, обычные офисные приложения вполне будут работать в режиме vSGA:
А вот некоторые пользователи тяжелых графических программ (например, Adobe Premiere) будут чувствовать себя комфортно только в режиме vDGA:
Режим vSGA
Идем дальше. Режим vSGA - это самый простой и эффективный способ использовать аппаратное ускорение для 3D-графики в виртуальных машинах. Он ограничивает системного администратора только объемом видеопамяти, которой, однако, у адаптера тоже не бесконечно много. На март этого года для режима vSGA поддерживаются следующие адаптеры:
Nvidia GRID K1
NvidiaGRID K2
Nvidia Quadro 4000
Nvidia Quadro 5000
Nvidia Quadro 6000
Nvidia Tesla M2070Q
В режиме vSGA есть три варианта использования:
Automatic - аппаратное ускорение будет использовано только в случае доступного и подходящего GPU на хосте, где эта ВМ запущена. Если такого нет - то используется софтверный рендер. Когда машина переместится на подходящий хост - включится режим vSGA.
Software only - всегда используется софтверный рендер (даже если есть свободные ресурсы GPU). Эта конфигурация работает на любом хосте.
Hardware only - обязательное использование аппаратного ускорения. В этом случае проверяются условия при старте или миграции виртуальной машины на другой хост. Если они не выполняются - этого не происходит.
Disabled - 3D-рендеринг не используется вовсе.
В плане драйвера гостевой ОС используется стандартный драйвер VMware SVGA 3D graphics. Но на сам ESXi нужно поставить специальные VIB-пакеты, которые будут обеспечивать работу виртуальных машин в режиме vSGA. Например, драйвер для ESXi 5.1 находится тут, а для ESXi 5.5 - тут.
Режим vDGA
Этот режим предназначен для случая, когда отдельный GPU нужно целиком и полностью отдать виртуальной машине. Этот режим основан на технологии VMware vSphere DirectPath I/O (то есть, прямой проброс устройств). Соответственно, здесь важно количество GPU на хосте VMware ESXi, которое и определяет максимальное количество запущенных виртуальных машин с поддержкой vDGA. Ну а максимальное число таких GPU на сервере определяется числом слотов PCIe x16 (нужно множить на число GPU у одного адаптера).
Например, на сервере Dell R720 может быть две карты NVIDIA GRID K2, каждая из которых имеет 2 GPU. Таким образом, максимальное количество виртуальных машин с поддержкой vDGA может быть четыре штуки.
В случае с vDGA используется драйвер от вендора, который и занимается работой с нижележащим оборудованием и видеокартой. На данный момент режим vDGA поддерживается для следующих графических адаптеров:
Nvidia GRID K1
Nvidia GRID K2
Nvidia Quadro K2000
Nvidia Quadro K4000
Nvidia Quadro K5000
Nvidia Quadro K6000
Nvidia Quadro 1000M
Nvidia Quadro 2000
Nvidia Quadro 3000M
Nvidia Quadro 4000
Nvidia Quadro 5000
Nvidia Quadro 6000
Nvidia Tesla M2070Q
Кстати, при использовании таких адаптеров нужно учитывать электропитание серверов, так как, например, NVIDIA Quadro 6000 GPU использует до 200 Ватт мощности.
Если объединить специфику режимов софтверного рендера, vSGA и vDGA получится вот такая табличка:
Тут надо отметить, что как для vSGA, так и для vDGA режимов поддерживаются только гостевые ОС Windows 7 (для vSGA - x86 и x64, для vDGA - только x64).
Текущее выделение графических адаптеров и режим их работы можно проверить следующей командой на сервере VMware ESXi:
# gpuvm
Вывод будет примерно таким:
# gpuvm
Xserver unix:0, GPU maximum memory 2076672KB
pid 118561, VM “Test-VM-001”, reserved 131072KB of GPU memory
pid 664081, VM “Test-VM-002”, reserved 261120KB of GPU memory
GPU memory left 1684480KB
В рамках акции предоставляются специальные условия на приобретение блочных систем хранения данных NetApp E2700. Основными областями применения данных систем являются: full motion видео, медиа контент, обработка сейсмических данных, видеонаблюдение, высокопроизводительные вычислительные кластера (HPC), D2D бэкап, геологоразведка и др.
Отличительной особенностью являются более низкая стоимость за терабайт полезного пространства по сравнению с FAS-моделями.
NetApp E2700
Высокопроизводительный модульный массив, бюджетное, отказоустойчивое, масштабируемое решение для хранения данных, предоставляющее доступ по протоколам FC, ISCSI и SAS.
Код бандла
Количество контроллеров
Количество HDD
Платы расширения
E2700-B1
2 = Dual
12HDD x 2TB
16Gb FC 2 Port
(8Gb SFPs)
E2700-B2
2 = Dual
12HDD x 4TB
16Gb FC 2 Port
(8Gb SFPs)
E2700-B3
2 = Dual
12HDD x 2TB
10Gb iSCSI
E2700-B4
2 = Dual
12HDD x 4TB
10Gb iSCSI
E2700-B5
1 = Single
12HDD x 2TB
Нет
E2700-B6
1 = Single
12HDD x 4TB
Нет
Во все комплекты, если предусмотрено производителем, входят SFP-модули, кабели и рельсы для крепления в стойке.
Подписка на ПО и гарантия на оборудование - 36 месяцев.
Системы хранения данных NetApp серии FAS8000 — это сочетание унифицированной горизонтально масштабируемой архитектуры с лидирующими функциями управления данными. Системы отличаются быстрой адаптацией к меняющимся потребностям предприятия и соответствуют требованиям к продолжительности безотказной работы, масштабируемости и рентабельности.
Быстрое выполнение бизнес-операций. Выгодно используя высокие показатели производительности, а также преимущества многоядерной архитектуры и самоуправляемых флэш-технологий ускорения, унифицированные горизонтально масштабируемые СХД FAS8000 увеличивают пропускную способность и уменьшают время ожидания, обеспечивая стабильную работу приложений с разнородными рабочими нагрузками SAN и NAS.
Рационализация ИТ-операций. Благодаря упрощенному управлению и апробированной интеграции со средами поставщиков облачных услуг вы можете смело внедрять систему FAS8000 в свой центр обработки данных и гибридное облако. Бесперебойные операции упрощают долговременный процесс масштабирования и увеличивают период бесперебойной работы, обеспечивая проведение ремонта аппаратных компонентов, модернизацию технических средств и других обновлений без отключения системы.
Обеспечение эффективного показателя общей стоимости владения. Апробированные технологии повышения эффективности и отличное соотношение «цена-производительность» оптимизируют занимаемое дисковое пространство и улучшают показатели окупаемости в долгосрочной перспективе. Программное обеспечение виртуализации СХД FlexArray позволит интегрировать существующие массивы с системами FAS8000, повышая уровень консолидации и ценность вашего бизнеса.
Для получения более детальной информации о дисковых массивах NetApp - обращайтесь в компанию ИТ-ГРАД. Там специальные цены!
На днях компании VMware и Google сделали интересное совместное заявление: теперь VDI-инфраструктура VMware Horizon View будет полноценно поддерживаться на устройствах Chromebook различных производителей. Таким образом, два софтверных гиганта будут совместно улучшать решение:
Пресс-релиз по этому поводу от VMware доступен тут, а от Google - вот тут. Суть данной инициативы проста - грядет эра ПК как услуги (Desktop as a Service, DaaS), многие пользователи хотят потреблять десктоп из облака, не имея при этом на своем компьютере ничего кроме браузера (собственно, для этого хромбук и нужен). Для решения этой задачи вполне подходят устройства Chromebook (или Chromebox), в которых можно показывать виртуальные ПК пользователя через браузер с поддержкой HTML 5.
Мы уже много писали о технологии AppBlast, которая позволяет отображать виртуальный ПК прямо в браузере с использованием HTML 5 по протоколу Blast. Напомним, что эта штука появилась еще в решении VMware View 5.2. И она уже сейчас работает в хромбуках.
В последнее время появилось несколько новых хромбуков с приличным железом по доступной даже для небольших компаний цене. Например, вот эта штука от HP за $449 с консолью управления (как раз бизнес-функции по управлению ПК) и поддержкой:
Позиционируется эта инициатива не только как решение по доступу к ресурсам частного облака на базе VMware Horizon View, но и как возможность доступа к DaaS-инфраструктуре сервис-провайдеров (см. решение Desktone, которое купила VMware).
Те, кто заинтересовался совместным решением Google и VMware, могут прийти на специальный вебинар о данной инициативе, который состоится 13 марта. Таким образом, на рынке появится еще одно интересное программно-аппаратное решение для организации VDI-инфраструктуры.
И, кстати, в США хромбуки делают 21% продаж лэптопов (данные 2013 г.), а значит у этой инициативы большое будущее.
Компания NetApp представила свои новые аппаратные платформы, отвечающие требованиям к производительности приложений, работающих с большими объемами данных. Представленные обновления полностью соответствуют инновационной стратегии NetApp, направленной на разработку ускоренных при помощи флэш-технологий и интегрируемых в облачные архитектуры решений хранения данных для широкого спектра разделяемых и специализированных ИТ-инфраструктур. Более подробно узнать о решениях NetApp, протестировать и заказать их можно на сайте компании ИТ-ГРАД.
Флеш-массив NetApp EF550
Массив NetApp EF550 Flash Array разработан для высокопроизводительных приложений, допустимое время ожидания для которых исчисляется долями миллисекунды.
Флэш-массив NetApp EF550® обеспечивает исключительную производительность, эффективность ИТ и надежность для критически важных приложений, увеличивая скорость их работы и сокращая время ожидания.
СХД корпоративного класса NetApp EF550 на базе дисков SSD позволяет:
ускорить процессы бизнеса благодаря времени отклика, составляющему всего доли миллисекунды;
устранить избыточное выделение ресурсов и повысить эффективность ИТ;
добиться операционной производительности, эквивалентной работе 1000 традиционных дисков (15 000 об/мин), используя корпус 2U, который задействует всего 5% пространства стойки, ресурсов питания и охлаждения;
быстро определять и устранять возможные проблемы с помощью расширенных возможностей мониторинга и проактивного устранения неисправностей;
обеспечить защиту от потери данных и устранить простои благодаря копиям NetApp Snapshot, удаленной репликации и прочим функциям защиты данных;
выполнять репликацию данных на СХД EF550 или NetApp E-Series;
воспользоваться преимуществами корпоративной программной платформы ПО SANtricity.
Высокие показатели IOPS, время ожидания, составляющее всего доли миллисекунды, возможность масштабирования и надежность корпоративного класса флэш-массива NetApp EF550 позволяют ускорить выполнение рабочих процессов и быстрее получить желаемые результаты.
Обновления E-Series – E2700 и Е5500
E-Series включена в линейку решений NetApp для блочных систем хранения данных с повышенной производительностью. Системы E-Series легко масштабируются и предназначены для рабочих нагрузок, требующих 99,999% надежности при устойчиво высокой производительности.
Новый массив хранения данных NetApp E2700 SAN
Масштабируемая NetApp E2700 представляет собой решение общего назначения для хранения данных приложений, которое подходит для филиалов, удаленных офисов и предприятий среднего бизнеса. На выбор доступны три вида полок — 4U/60, 2U/24 и 2U/12, а также три интерфейса для подключения: FC, iSCSI или SAS. E2700 интегрируется с основными приложениями, включая системы VMware, Exchange, SQL и Oracle.
NetApp E2700 позволяет:
добиться высочайшего в своем классе уровня производительности для широкого ряда баз данных и других транзакционных приложений;
упростить и снизить затраты на управление данными с высокой пропускной способностью с помощью конфигурируемой архитектуры, простой в использовании и установке;
оптимизировать производительность, сократить время ожидания, увеличить пропускную способность и показатель IOPS;
обеспечить бесперебойность операций с помощью гибкой интеграции приложений;
масштабировать дисковое пространство по мере роста предприятия.
Как и другие NetApp E-Series, E2700 использует надежное, простое в использовании и экономичное ПО для управления СХД SANtricity.
Это программное обеспечение позволяет повысить уровень производительности и эффективности, обеспечивает динамическое распределение дисковых ресурсов и управление RAID, а также включает в себя технологию Intelligent Cache Tiering (разделение уровней хранения с помощью интеллектуального кэширования) и расширенные возможности защиты данных, в том числе репликацию и аварийное восстановление данных.
Обновленный массив NetApp E5500 SAN
Высокопроизводительная система E5500 расширяет возможности защиты данных благодаря использованию инструментального пакета SANtricity с функциями репликации данных и гибким интерфейсом. Система предлагается с дисками iSCSI объемом 10 Гбайт и дисками FC объемом 16 Гбайт.
Программа NetApp AutoSupport обеспечивает пользователям возможность контроля всего предприятия и содержит встроенные средства аналитики для проактивного управления. E5500 может поддерживать объем памяти до 1,5 Пбайт на одну систему, необходимый для крупномасштабных систем обработки данных.
За консультацией по данному оборудованию обращайтесь в компанию ИТ-ГРАД.
Несколько недель назад компания VMware выпустила обновление ESXi 5.5.0 Driver Rollup 1, представляющее собой ISO-образ с самим ESXi 5.5 и дополнительными драйверами. Этот образ подходит только для чистой установки на хост и не поддерживает режим обновления (Upgrade).
VMware ESXi 5.5.0 Driver Rollup 1 содержит в себе драйверы IOVP certified drivers (IOVP - I/O Vendor Partner Program), то есть драйверы от производителей, которые добавились или обновились с момента выхода ESXi 5.5.
Обновлены были драйверы оборудования следующих производителей:
Broadcom
Cisco
Emulex
Fusion-io
HP
Hitachi
Intel
LSI Corporation
QLogic
Virident Systems
Release Notes для ESXi 5.5.0 Driver Rollup 1 доступны по этой ссылке.
Продолжаем рассказывать об услугах компании ИТ-ГРАД - первого сервис-провайдера в России, предоставляющего в аренду виртуальные машины на платформе VMware.
Помимо услуг IaaS (Infrastructure-as-a-Service) компания ИТ-ГРАД занимается поставкой уже готовых комплексов для создания виртуальной инфраструктуры. Комплексы укомплектованы всем необходимым для начала работы и не требуют дополнительного оборудования. Опциональные возможности позволяют легко наращивать производительность любого комплекса, либо изменять его качественные характеристики.
Предлагаемые решения являются результатом многолетнего опыта компании по построению инфраструктуры приватных облаков на базе продуктов VMware. Все применяемые компоненты одобрены к использованию компанией VMware для построения виртуального датацентра на базе VMware vSphere 4.1 и выше. Все комплексы полностью протестированы в Центре Компетенции, и ИТ-ГРАД гарантирует их работоспособность и эффективность.
Более подробно узнать о составе и функциях облачных комплектов от ИТ-ГРАД, а также ознакомиться с возможностями комплекта для построения инфраструктуры 3D VDI, можно по этой ссылке.
На этот раз сайте компании ИТ-ГРАД появился отличный обзор платформы Dell VRTX, где показывают как выглядит «идеальное серверное решение для средних и малых предприятий, удаленных офисов и филиалов». Dell VRTX сочетает в себе интегрированные серверы, систему хранения данных и сетевые компоненты в компактном корпусе, оптимизированном для офисных сред.
Решение VRTX может включать в себя до четырех серверов 12-го поколения Dell PowerEdge M620 (или M520) и встроенный коммутатор 1GbE с 16 внутренними портами 1GbE и 8 внешними портами в стандартной комплектации.
Коробка с шасси и дисками весит около 50 кг, блейд-сервера легче, они упакованы в индивидуальные коробки. Вытаскиваем массивную железную корзину, за картонные ручки по бокам. Ставим на пол.
Вес корзины (пустой) равен 24.7кг, вес максимальный = 68.7кг.
Размеры корзины внушительны и занимают 5 юнитов в высоту. По габаритам (В х Ш х Г): 21.9 см х 48.2 см х 73.0 см.
Всю систему можно разделить на 2 части – верхняя для системы хранения данных, нижняя – для серверных модулей.
Дисковая корзина содержит 25 SAS дисков емкостью 900 ГБ, скоростью вращения 10К и размером 2,5'. Суммарная емкость корзины насчитывает 30 ТБ. Есть и другая конфигурация, содержащая 12 накопителей форм-фактора 3,5’’ и суммарной емкостью 48 ТБ.
На этот раз сайте компании ИТ-ГРАД появился отличный обзор платформы Dell VRTX, где показывают как выглядит «идеальное серверное решение для средних и малых предприятий, удаленных офисов и филиалов». Dell VRTX сочетает в себе интегрированные серверы, систему хранения данных и сетевые компоненты в компактном корпусе, оптимизированном для офисных сред.
Решение VRTX может включать в себя до четырех серверов 12-го поколения Dell PowerEdge M620 (или M520) и встроенный коммутатор 1GbE с 16 внутренними портами 1GbE и 8 внешними портами в стандартной комплектации.
Коробка с шасси и дисками весит около 50 кг, блейд-сервера легче, они упакованы в индивидуальные коробки. Вытаскиваем массивную железную корзину, за картонные ручки по бокам. Ставим на пол.
Вес корзины (пустой) равен 24.7кг, вес максимальный = 68.7кг.
Размеры корзины внушительны и занимают 5 юнитов в высоту. По габаритам (В х Ш х Г): 21.9 см х 48.2 см х 73.0 см.
Всю систему можно разделить на 2 части – верхняя для системы хранения данных, нижняя – для серверных модулей.
Дисковая корзина содержит 25 SAS дисков емкостью 900 ГБ, скоростью вращения 10К и размером 2,5'. Суммарная емкость корзины насчитывает 30 ТБ. Есть и другая конфигурация, содержащая 12 накопителей форм-фактора 3,5’’ и суммарной емкостью 48 ТБ.
Сегодня мы хотим рассказать еще о двух вещах. Во-первых, компания VMware выпустила обновление беты Virtual SAN, которое получило следующие новые возможности:
AHCI fix - как писала VMware ранее, была проблема с контроллерами AHCI, которая приводила к потере данных на устройствах VSAN (см. PDL, Permanent Device Loss). Теперь эту проблему исправили, и можно продолжать тестирование на этих контроллерах.
New RVC Commands - теперь в Ruby Virtual Console, которая входит в состав VMware vCenter 5.5, есть команды по управлению хранилищами в пространстве имен spbm (Storage Policy Based Management). Существующие политики можно найти в папке "~/storage/vmprofiles".
PowerCLI fling - многим пользователям интересна автоматизация задач в VMware vCloud Suite. Теперь и для VSAN есть набор командлетов PowerCLI, которые позволяют управлять хранилищами VSAN. Более подробно об этом здесь.
Limit Changes - в первой бета-версии дисковая группа могла иметь 1 SSD-Накопитель и до 6 HDD-дисков, но поскольку есть серверы, в которых восемь слотов, то HDD-дисков теперь поддерживается до 7 штук (SSD по-прежнему один).
В этот раз сравнивалось некий дисковый массив "all flash storage array", который работает на SSD-накопителях, и 7-ми и 8-ми узловые кластеры Virtual SAN. Результаты в очках, поставленных VDImark (View Planner QoS), поставленные кластеру из хостовых хранилищ и дисковому массиву:
Напомним, что очки VDImark - это число виртуальных машин, которое может быть запущено на данной аппаратной конфигурации с соблюдением определенного порогового значения для операций (на самом деле минимум 95% операций должны попасть в эти трешхолды для ВМ, чтобы их засчитали).
Результаты тестов оказались весьма неплохими. Картинка для тестов по времени отклика операций группы А (интерактивные операции пользователя):
Группа B:
Вывод: Virtual SAN - очень неплох в сравнении с нативной производительностью какого-то SSD-массива (VMware, что это за массив-то??).
Как вы знаете, в VMware vSphere 5.5 и VMware Horizon View 5.3 в гостевых ОС виртуальных машин поддерживаются функции гостевых систем по обработке 3D-графики на стороне сервера за счет использования следующих режимов:
Soft 3D - рендеринг 3D-картинки без использования адаптера на основе программных техник с использованием памяти сервера.
vDGA - выделение графического адаптера (GPU) отдельной виртуальной машине.
vSGA - использование общего графического адаптера несколькими виртуальными машинами.
Естественно, для всего этого необходимы специальные серверные видеоадаптеры, поддерживающие режимы vDGA и vSGA, например, NVIDIA Grid K1 и K2.
Однако справедливости ради надо отметить, что несмотря на то, что NVIDIA является пионером визуализации 3D-графики в виртуальных машинах VMware, и там режимы vDGA/vSGA уже работают, поддержка данных техник также заявлена и в адаптерах AMD (но на данный момент, судя по всему, это не совсем полноценно работает). Функции vSGA и vDGA поддерживаются следующими графическими адаптерами:
NVIDIA
Grid K1 and K2
Quadro 4000/5000/6000
Tesla M2070Q
AMD
FirePro S7000 /S9000/S10000
FirePro v7800P/V9800P
С точки зрения платформы виртуализации, гостевых ОС и прочего виртуальные машины с поддержкой vDGA должны удовлетворять следующим требованиям:
Платформа VMware vSphere 5.1 или более поздней версии (в 5.5 функции шире), для виртуальных ПК - VMware Horizon View 5.2 или более поздняя версия (5.3).
Использование одного из клиентов vSphere либо VMware Workstation.
ВМ с гостевой ОС Windows 7 или Windows 8 если используется vSphere / View. Для режима vDGA поддерживаются только 64-битные ОС.
ВМ с гостевыми ОС Fedora 10+/Ubuntu 12+ (только на платформе vSphere).
В настройках виртуальной машины нужно включить поддержку 3D-графики (если используется режим vSGA, для vDGA - это не нужно).
Необходимы VIB-модули для VMware ESXi от производителя графического адаптера (например, для NVIDIA их можно найти тут). Они разрабатываются и поддерживаются NVIDIA и AMD - не VMware. VIB-модули нужно ставить только для режима vSGA.
Для виртуальных ПК необходим клиент на базе протокола PCoIP или HTML-клиент (протокол Blast).
Уже довольно давно мы писали про техники кэширования в продукте StarWind iSCSI SAN & NAS, который предназначен для создания отказоустойчивых iSCSI-хранилищ под виртуальные машины. Эти техники постоянно совершенствуются (см., например, новые возможности StarWind V8 Beta 2) и иногда в разы увеличивают быстродействие виртуальных машин, особенно в условиях высоких требований к подсистеме ввода-вывода.
У некоторых пользователей возникает вопрос - а нужно ли использовать кэш StarWind, когда на сервере используется SAS-адаптер со своим кэшем, например, HP Smart Array P420, имеющий на борту 1GB RAM. На форуме StarWind Антон отвечает на этот вопрос следующим образом:
У кэша контроллера весьма ограниченный объем, а StarWind может использовать очень большой объем RAM для оптимизации ввода-вывода.
Кэш контроллера медленный, так как использует шину PCIe, а кэш StarWind - быстрый, так как использует шину оперативной памяти.
Кэш контроллера небезопасен - только одна копия данных. При использовании кэширования StarWind метаданные дублируются и даже "триплируются" при использовании трехузлового кластера. Вероятность, что все хосты кластера хранилищ упадут одновременно - очень низка.
Кэш контроллера работает только для одного узла, то есть когда ВМ переезжает с этого узла - она уже не имеет доступа к своему кэшу. StarWind же имеет умную систему распределенного кэша между узлами, и когда виртуальная машина переезжает на другой хост кластера хранилищ, она продолжает его использование.
Таким образом, вывод прост - конечно же, включайте кэширование на уровне SCSI-адаптера, но не подразумевайте это как альтернативу кэшированию StarWind, так как последнее - более умная и эффективная технология, разработанная изначально для виртуальных машин.
Не так давно компания NVIDIA объявила о том, что технология NVIDIA GRID (о которой мы писали вот тут и тут) теперь доступна через Amazon Web Services (AWS) в новом инстансе Amazon Elastic Compute Cloud (Amazon EC2) G2, что позволяет использовать GPU-ускорение требовательных к графике приложений и игр для «облачных» пользователей.
Используя технологию NVIDIA GRID, компании, предоставляющие программное обеспечение как услугу (SaaS-провайдеры), теперь могут предлагать в аренду облачные сервисы с высокой производительностью графики для проектирования, визуализации изображений, создания медиаконтента, игр и других требовательных к вычислительным ресурсам приложений. Да, на этих машинах можно будет полноценно играть в 3D-игры!
Клиенты облака Amazon EC2 теперь могут использовать два новых инстанса - g2.2xlarge и cg1.4xlarge. Машина на базе g2.2xlarge представляет из себя следующее:
Графический процессор NVIDIA GRID на базе GK105 Kepler с ядрами 1536 CUDA и 4 ГБ оперативной памяти.
Процессор Intel Sandy Bridge 2,6 ГГц с технологией Turbo Boost и 8 vCPU.
15 ГБ RAM.
60 ГБ хранилища на SSD-дисках.
10 Gigabit Ethernet.
Второй инстанс (cg1.4xlarge) предназначен для HPC-нагрузок. Там используется более мощный модуль GPGPU (General Purpose Graphics Processing Unit) и технология error-correcting memory.
На данный момент эти инстансы доступны только в следующих датацентрах: US East (Northern Virginia), US West (Northern California), US West (Oregon) и EU (Ireland).
Основанные на архитектуре NVIDIA Kepler графические процессоры GRID оснащены кодером H.264, который позволяет сжимать графику высокого разрешения в реальном времени и передавать ее на любое подключенное к интернету устройство. Один GPU может поддерживать до восьми HD-видеопотоков в реальном времени (720p / 30 fps) или до четырех Full-HD потоков (1080p / 30 fps).
Чтобы упростить развертывание приложений на инстансах G2, компания OTOY добавила связующее ПО OTOY ORBX к образу AMI (Amazon Machine Image) на базе Windows и Linux. SaaS-компании могут устанавливать свои приложения в OTOY AMI и сразу же предоставлять к ним доступ по сети.
Кстати, в данный момент OTOY и Autodesk разрабатывают технологию, которая предоставит доступ к самым популярным приложениям проектирования Autodesk через OTOY AMI.
Вот такое можно будет делать прямо в браузере:
Цена инстансов будет такова: G2 обойдется по цене от $0.294 за час, цена же на cg1.4xlarge еще не определена.
С выходом обновленной версии платформы виртуализации VMware vSphere 5.5 компания VMware ввела новую модель Native Device Driver Architecture, которая позволяет использовать нативные драйверы для VMkernel вместо драйверов под Linux.
Однако, помимо этого нововведения, VMware также убрала и неофициальную поддержку многих SATA-контроллеров, которые раньше и не заявлялись как работающие, но вполне нормально функционировали на whitebox-конфигурациях (например, контроллеры ASMedia и Marvell). Теперь многие SATA-контроллеры в ESXi 5.5 просто не работают.
Но не все так плохо. Поскольку поддержка старой модели драйверов еще осталась (неизвестно будет ли она в следующей версии ESXi, но скорее всего будет, так как не все партнеры успеют перейти на новую модель), то можно заставить работать некоторые неподдерживаемые контроллеры SATA AHCI, поскольку сам драйвер AHCI остался в виде модуля VMkernel (ahci). Andreas Peetz не только написал хорошую статью о том, как это сделать, но и сделал кастомные VIB-пакеты для добавления поддержки некоторых SATA-контроллеров AHCI.
Суть такая - автор раньше думал, что команда vmkload_mod ahci заставляет ESXi загружать драйверы для всех обнаруженных PCI-устройств, то оказалось, что она конфигурирует только устройства, которые есть в файле /etc/vmware/driver.map.d/ahci.map. А там неподдерживаемых девайсов не появляется. Поэтому надо сделать отдельный map-файл и добавить ссылки соответствующих устройств (их PCI ID) на драйвер AHCI.
Андреас сделал VIB-пакет позволяющий добавить поддержку ESXi следующих SATA-контроллеров:
ASMedia Technology Inc. ASM1061 SATA IDE Controller (1b21:0611)
ASMedia Technology Inc. ASM1062 Serial ATA Controller (1b21:0612)
Marvell Technology Group Ltd. 88SE9123 PCIe SATA 6.0 Gb/s controller (1b4b:9123)
Marvell Technology Group Ltd. 88SE9172 SATA 6Gb/s Controller (1b4b:9172)
В каментах Андреас принимает заявки на добавление поддержки нужных SATA-контроллеров, так что если их в приведенном выше списке - пишите ему и он добавит.
Процедура добавления поддержки контроллеров такова. Добавляем возможность использования кастомных драйверов на ESXi:
esxcli software acceptance set --level=CommunitySupported
Разрешаем использование http на хосте в фаерволе:
esxcli network firewall ruleset set -e true -r httpClient
Немногие знают, что с выходом обновленной платформы виртуализации VMware vSphere 5.5 компания VMware поменяла архитектуру драйверов, которые использует гипервизор для взаимодействия с аппаратным обеспечением. Теперь эта архитектура называется Native Device Driver Architecture, и она позволяет использовать нативные драйверы для VMkernel вместо драйверов под Linux.
William Lam написал хороший пост на эту тему. Изложим здесь его основные моменты вкратце.
Раньше VMware ESX / ESXi использовал архитектуру драйверов Linux, но поскольку ядро гипервизора VMkernel - это не Linux, то VMware пришлось сделать модуль vmklinux, который находится между VMkernel и драйверами:
Эта архитектура позволяет драйверам "Linux-происхождения" общаться с VMkernel через API, предоставляемый vmklinux.
Однако очевидно, что у такой архитектуры есть множество недостатков:
Дополнительный уровень трансляции команд добавляет багоемкости и потерь производительности.
Необходима совместимость драйверов с ядром Linux, хотя требуется-то всего лишь совместимость с VMkernel.
Ограниченность функциональности драйвера - он может сделать для VMkernel не больше, чем может сделать для Linux.
Ввиду всего этого в VMware ESXi 5.5 и была введена новая архитектура, в которой отсутствует ненужная прослойка:
Теперь VMware предоставляет своим партнерам средство разработки Native Driver Development Kit (NDDK), которое позволяет производителям аппаратного обеспечения делать нативные драйверы для VMware ESXi / VMkernel как для отдельной ОС. Доступна эта возможность только партнерам уровня TAP (Technology Alliance Partner).
С одной стороны это все выглядит позитивно, если бы не одно но. Если раньше Linux-драйверы, которые выпускались под лицензией GPL, были доступны как open source, то и исходные коды драйверов для ESXi (в соответствии с лицензией GPL) были также доступны публично.
Поэтому независимые разработчики могли использовать их для разработки собственных и доработки существующих драйверов к устройствам, официально неподдерживаемым VMware ESXi (для так называемого "Whitebox-железа").
Теперь же VMware не планирует выпускать драйверы как Open Source, что сильно ограничит возможности по поддержке аппаратных компонентов и платформ, отсутствующих в списке совместимости HCL.
Платформа виртуализации VMware vSphere 5.5 на данный момент поддерживает как legacy-модель драйверов, так и Native Device Driver Architecture в целях обратной совместимости. Однако рано или поздно VMware откажется от поддержки Linux-драйверов, и многим пользователям такое не понравится.
Поэтому VMware просто обязана предоставить всем разработчикам свободный доступ к NDDK, а не только TAP-партнерам, чтобы сохранить хорошую репутацию в такой ситуации.
Как мы уже недавно писали, одной из новых возможностей VMware vSphere 5.5 стали функции расширенного управления электропитанием серверов vSphere Host Power Management (HPM). Ранее о таких функциях на платформе VMware vSphere мы рассказыали вот тут.
HPM - это совокупность техник, позволяющих оптимизировать потребление электроэнергии хостом VMware ESXi, когда он находится в состоянии простоя или пониженной нагрузки.
Управление электропитанием происходит через интерфейс Advanced Configuration and Power Interface (ACPI), который позволяет управлять состояниями P-states и C-states. В VMware vSphere 5.0/5.1 дефолтная политика управления питанием была основана на технологии dynamic voltage and frequency scaling (DVFS).
Эта технология использует P-states процессора, что позволяет экономить некоторое количество энергии за счет поддержки процессора на более низкой частоте и напряжении. Но, начиная с VMware vSphere 5.5, политика HPM использует расширенный набор состояний halt states (они же C-states) в дополнение к DVFS. Это намного больше увеличивает экономию энергии при сохранении хорошей производительности, так как состояния C-states процессора почти не сказываются на его производительности, а питания потребляют значительно меньше (а иногда производительность даже растет, особенно для легких и средних нагрузок без большого потока операций ввода-вывода).
Так как теперь ESXi использует весь спектр возможностей по управлению питанием хоста, то в BIOS большинства серверов нужно предоставить гипервизору полномочия на действия по оптимизации энергопотребления процессора. По умолчанию на большинстве серверов такие функции выключены.
Для того чтобы их включить, например, в серверах HP нужно в BIOS зайти в Power Management Options -> HP Power Profile и выбрать пункт Custom. Затем нужно зайти в Power Management Options->HP Power Regulator, где выбрать пункт OS Control Mode.
Для управления глубокими режимами C-states (C1/C1E, C3 и C6) нужно также разрешить их использование со стороны программного обеспечения в BIOS сервера:
Для VMware HPM есть 4 различных политики электропитания:
High Performance - в этом состоянии процессор находится в самом высоком P-state все время, а для C-states используется всего 2 режима: running и halted. Это дефолтная политика для vSphere 5.0 и более ранних версий.
Balanced - вот эта политика и позволяет использовать как P-states для экономии питания, так и, начиная с vSphere 5.5, C-states, выбор которых производится на основе оценки со стороны ESXi с использованием статистического прогноза на время простоя процессора.
Low Power - в этом режиме хост делает все, чтобы снизить потребление энергии, используя алгоритмы P-states и C-states состояний.
Custom - по умолчанию эта политика выставлена как Balanced, но ее уже можно крутить для получения нужного результата.
Для политики Custom есть несколько интересных параметров, которые можно покрутить, если очень хочется (их число по сравнению с прошлой версией ESXi возросло):
По результатам тестов использование C-states для режима Turbo mode дает существенный прирост производительности (при том, что само по себе включение турбо-режима прироста почти не дает):
А вот как использование deep C-states позитивно влияет на потребление электроэнергии:
Интересный график экономии питания в зависимости от нагрузки хост-сервера - получается, что максимальная эффективность у HPM - до 30% загрузки CPU:
Не так давно мы писали про средства управления питанием хост-серверов ESXi, которые имеются в VMware vSphere 5.1. Там мы рассматривали такую политику как Balanced - она разработана для того, чтобы максимально использовать переключения между состояниями P-states процессора в целях экономии энергии. Она обладает слегка большей инерционностью, чем обычное максимальное использование ресурсов процессора (High performance), но почти не влияет на производительность. Эта политика выставлена по умолчанию для серверов VMware ESXi 5.0 и более поздней версии.
Недавно на блоге VROOM! компании VMware появилось интересное исследование, посвященное механизмам управления питанием серверов ESXi. Как и обычно, в качестве инструмента для тестирования и создания нагрузки на хосты ESXi использовался продукт VMware VMmark, который и был разработан для тестирования производительности решений VMware на различных аппаратных платформах.
Сравнивались три подхода к управлению питанием:
Политика Performance - максимальное использование процессора за счет его поддержки в наивысшем P-state состоянии все время (то есть, по-сути политика энергосбережения отключена). При этом используются только 2 C-state состояния: С0 (running) и C1 (halted). Соответственно, данный режим выдает максимальную производительность, не имеет инерционности и потребляет больше всего энергии. Управляется эта политика BIOS'ом сервера.
Политика Balanced - сбалансированное энергопотребление за счет переключения между P-states. Эта политика управляется хостом ESXi.
Политика BIOS Balanced - функции энергосбережения, которые управляются на уровне BIOS сервера (например, Dell Active Power Controller).
Для тестирования производительности использовался стандартный подход VMmark, который предполагает создание возрастающих уровней нагрузки на хост-серверы (Tiles).
С точки зрения аппаратной платформы, использовалась следующая конфигурация:
4 сервера Dell PowerEdge R620
CPUs (на сервер): один Eight-Core Intel® Xeon® E5-2665 @ 2.4 GHz, Hyper-Threading enabled
Memory (на сервер): 96GB DDR3 ECC @ 1067 MHz
Host Bus Adapter: два QLogic QLE2562, Dual Port 8Gb Fibre Channel to PCI Express
Network Controller: один Intel Gigabit Quad Port I350 Adapter
Версия гипервизора: VMware ESXi 5.1.0
Дисковый массив: EMC VNX5700
62 флеш-диска (SSDs), RAID 0, сгруппированных в 3 x 8 SSD LUNs, 7 x 5 SSD LUNs и 1 x 3 SSD LUN
Средства управления: VMware vCenter Server 5.1.0
Версия VMmark: 2.5
Power Meters: три устройства Yokogawa WT210
Итак, что получилось. График очков VMmark (чем выше столбики - тем лучше). Результаты нормализованы к BIOS Balanced на уровне Tile 1:
Как мы видим, худшие результаты показывает политика BIOS Balanced.
Теперь посмотрим на результаты тестов по новой методике VMmark 2.5, позволяющей измерять производительность сервера на киловатт питания:
Как мы видим, политика Performance показывает самые низкие результаты (это логично, так как энергии потребляется много, а столько мощности не всегда требуется процессору), политика ESXi Balanced показывает результат на 3% лучше, а вот политика BIOS Balanced - аж на 20% лучше.
Кстати, интересны измерения потребления мощности при простаивающем процессоре:
Политика Performance потребляет 128 Вт
ESXi Balanced - 85 Вт
BIOS Balanced - тоже около 85 Вт
Казалось бы, почему тогда не использовать BIOS Balanced? А вот почему - при тестировании нагрузки приложений политика BIOS Balanced выдает огромные задержки (latency), негативно влияющие на производительность:
Таким образом, если снова вернуться к первому графику с обобщенными результатами, можно понять, что политика ESXi Balanced является наиболее оптимальной с точки зрения энергопотребления/производительности, поэтому-то она и установлена по умолчанию.
Таги: VMware, ESXi, Performance, vSphere, Hardware, Power
В продолжение поста о распаковке системы Cisco UCS, приехавшей в Центр компетенции, компания ИТ-ГРАД рассказывает о Cisco UCS Manager, с помощью которого производится настройка всей системы. Данную задачу специалисты ИТ-ГРАД выполнили в рамках подготовки к тестированию FlexPod (Cisco UCS + NetApp в режиме MetroCluster) для одного из заказчиков. Отметим основные преимущества Cisco UCS, благодаря которым выбор пал именно на данную систему...
В этой части статьи разберем рекомендации по настройке взаимодействия физических клиентских устройств и виртуальных десктопов. С точки зрения информационной безопасности это важные ограничения, т.к. влияет явно на возможную передачу конфиденциальной информации между физическими клиентскими устройствами и виртуальными десктопами. Глобально пользователи должны использовать виртуальные десктопы в удаленном режиме (Remote Mode, Online). Т.е. физически виртуальные десктопы должны находиться на серверах, а не клиентских устройствах пользователей...
Многим интересующимся технологиями виртуализации известна компания Stratus Technologies, занимающаяся вопросами непрерывной доступности виртуальных машин (Fault Tolerance). Ранее продукты этой компании были доступны на платформе Citrix XenServer, где позволяли обеспечивать непрерывную доступность программными методами (продукт everRun от купленной компании Marathon):
Теперь у компании появился программно-аппаратный комплекс Stratus ftServer systems with vSphere 5.1, интегрированный с последней версией платформы виртуализации от VMware. Возможности решения из пресс-релиза:
Обещают аптайм на уровне 99.999%, что соответствует 5.26 минут простоя в год
Один или два 8-ядерных процессора Intel с поддержкой hyper-threading и архитектуры QuickPath
Полная поддержка SMP для построения архитектуры непрерывной доступности (vSMP?)
Встроенные интерфейсы 10Gb Ethernet
Проактивная система мониторинга, предупреждающая о возможных сбоях
Система обнаружения проблем в самом сервере и операционной системе, работающая без прерывания обслуживания виртуальных машин
Минимальный overhead (<5%) на систему виртуализации
Интеграция с VMware HA
Очевидно, что Stratus суетится накануне выхода программного vSMP Fault Tolerance от самой VMware.
Кстати в пресс-релизе по ftServer говорится о полугодовой гарантии на нулевой даунтайм в $50 000, покрывающей не только серверную часть, но и гипервизор (!). Так что торопитесь - возможно, парочка серверов от Stratus достанется вам совершенно бесплатно (учитывая тот набор багов, который мы видим в vSphere 5.1).
Компания HP обновила Firmware для своих серверов HP ProLiant, доступное для гипервизора VMware ESXi 5.0 и более поздних версий. Обновление доступно по этой ссылке.
Процесс обновления Firmware проходит из сервисной консоли серверов VMware ESXi, при этом предварительными требованиями является наличие следующих компонентов:
На днях компания Код Безопасности объявила о том, что сертификат ФСТЭК России на ПАК «Соболь» версии 3.0 был продлен до 07 декабря 2015 года. Сертификат подтверждает, что ПАК «Соболь версии 3.0 соответствует 2-му уровню контроля на отсутствие НДВ (в соответствии с требованиями РД Гостехкомиссии России) и может использоваться в автоматизированных системах до класса 1Б и в ИСПДн до класса К1 включительно.
ПАК «Соболь» версии 3.0 предназначен для реализации следующих защитных механизмов:
идентификация и аутентификация пользователей на входе в систему (непосредственно при запуске сервера);
ведение журнала безопасности;
сигнализация попыток нарушения защиты;
запрет загрузки с внешних носителей;
контроль конфигурации (PCI-устройств, ACPI, SMBIOS и оперативной памяти).
Более подробно о комплексе ПАК "Соболь" можно узнать по этой ссылке.
RSS
